GitHub Availability Report: March 2022 | The GitHub Blog
background
mysql1クラスタのリソース競合が原因
mysql1 とは
書き込み操作のみが影響を受け、読み取り操作は影響を受けなかった
コアサービスが復旧した後、GitHub Actionsのキューが飽和した
溜まったキューを消化させようとして (ジョブの遅延が) 長期の停止 (outage) として記載された
what we learned
ピーク時の操作に耐えられなかったと位置付けられる
一部の障害はデータベースの可視性 (visibility) の変更に由来した
すべての障害はプライマリDBの余裕のなさから来るクソクエリ耐性のなさが原因
optimizing for stability
クエリ改善に加えて、計算された方法でDBのキャパシティ増加を行う
// オートスケール的なものと解釈した
他の障害を起こすリスクを下げるため……
アラートの閾値を下げた (= より敏感に検知するようにした)
能動的にWebhookとActionsを制限するようにした
2022/3/14から2022/3/28の間にクエリを改善しqpsを50%, トランザクションボリュームを70%減らした // transaction volumeってnumber of txsということ? トランザクションあたりの読み書きするレコードの量?
minimizing impact to our users
ピーク時にはmigrationやteam synchronizationなどの影響を与えそうな機能を一時停止することにした
ピーク時にDBのパフォーマンス劣化がみられた場合、GitHub Actionsの実行を抑制しないといけないことがわかってきた
(起きてから報告するより) 影響が想定されるならあらかじめ知らせておくほうが望ましいと考えた
immediate changes
アラートの閾値を下げたので“running hot”になる前に (実際に事が起きる前に) 対処できるようになった
既に進めていたクラスタの分割 (to shard) を加速させた
Additional technial and organizational intiatives
内部的な手続・監視・変更リリースプロセスを調査するチームを作った
当初の課題は軽減され、アラート処理も改善したので再発防止できる自信がある